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ABSTRACT 

The purpose of this pilot-in-the-loop aircraft taxi simulation was to evaluate a 
NextGen concept for surface trajectory-based operations (STBO) in which air traffic 
control (ATC) issued taxi clearances with a required time of arrival (RTA) by Data 
Communications (DataComm). Flight deck avionics, driven by an error-nulling 
algorithm, displayed the speed needed to meet the RTA. To ensure robustness of the 
algorithm, the ability of 10 two-pilot crews to meet the RTA was tested in nine 
experimental trials representing a range of realistic conditions including a taxi route 
change, an RTA change, a departure clearance change, and a crossing traffic hold 
scenario. In some trials, these DataComm taxi clearances or clearance modifications 
were accompanied by ‘preview’ information, in which the airport map display 
showed a preview of the proposed route changes, including the necessary speed to 
meet the RTA. Overall, the results of this study show that with the aid of the RTA 
speed algorithm, pilots were able to meet their RTAs with very little time error in all 
of the robustness-testing scenarios. Results indicated that when taxi clearance 
changes were issued by DataComm only, pilots required longer notification 
distances than with voice communication. However, when the DataComm was 
accompanied by graphical preview, the notification distance required by pilots was 
equivalent to that for voice. 
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SURFACE TRAJECTORY-BASED OPERATIONS 


Surface operations are one aspect of the design of the next generation (NextGen; 
JPDO, 2009) of the National Airspace System. Research efforts in this phase of 
flight have focused on the development of surface traffic management (STM) 
systems for air traffic control (ATC) to provide taxi clearances enabling efficient 
airport operations and improved throughput. One such example of an STM system 
is the Spot and Runway Departure Advisor (SARDA), which estimates spot-to- 
runway taxi times based on the current average (Jung, 2010). Future STM systems 
will have associated aircraft arrival times (i.e., required time of arrival, RTA) at 
active runway thresholds so that aircraft can cross with minimal or no delay, and at 
the departure runway, enabling aircraft departure queue sequencing. Such future 
“full capability” STM systems will require aircraft to reach specified locations on 
the airport surface with relatively precise timing. For the flight deck, in order to 
achieve an RTA, pilots should be provided the aircraft speed required to reach the 
specified location at the specified time, since speed (actually, thrust) is what the 
pilots control with the throttles. These NextGen taxi operations with “taxi 
clearances and RTAs” are termed surface trajectory-based operations (STBO). 

The use of Data Communications (DataComm) in surface operations has several 
potential benefits (e.g., reduced radio congestion, elimination of misunderstandings, 
see Wargo and D’Arcy, 2011). However, one concern is that DataComm may not be 
appropriate for use in time-critical situations. Specifically, it has been suggested that 
taxi route changes during taxi and time-critical events may require that ATC revert 
to voice communication (Jakobi, 2007; Wargo and D’Arcy, 2011). 

1.1 Previous STBO Research 

Several experiments have assessed speed-based taxi clearances and their effect 
on pilots’ ability to meet an RTA from an initial ramp spot to the departing runway 
(Foyle, Hooey, Bakowski, Williams, and Kunkle, 2011). Foyle et al. (2011, Expt. 2) 
explored pilots’ ability to meet an RTA using a commanded speed, with no 
additional flight deck equipage. Pilots were instructed to comply with the 
commanded speed on straight segments and accelerate/decelerate “aggressively”. 
The primary measure of pilot performance on the taxi task was RTA error, 
calculated by subtracting the RTA from the observed arrival time. Results revealed 
that requiring pilots to comply with a commanded speed, without additional flight 
deck equipage, produced unacceptably large RTA errors. 

Foyle et al. (2011, Expt. 3) explored whether requiring pilots to follow specific 
acceleration/deceleration speed profiles and follow the speed command more 
precisely would decrease RTA error. By requiring pilots to taxi within +/- 1.5 kts of 
a commanded speed and with a specific speed profile, RTA error was quite 
accurate. However, these requirements required excessive visual attention to the 
head-down speed display. Fourteen out of eighteen pilots reported that the demand 
of maintaining the required speed conformance range in actual operations would 
compromise safety. 



The results of these two studies demonstrated that: 1) Simply incorporating a 
commanded speed requirement into the taxi clearance alone was not sufficient for 
good RTA performance; and, 2) When pilots were given clearances that required 
them to control their aircraft according to precise acceleration/deceleration speed 
profiles in addition to a commanded speed, RTA conformance was quite good — 
but, that added precision caused pilots to spend an unacceptable amount of time 
viewing/tracking the speed display. This suggests the need for a flight deck 
technology solution to aid pilots in safely meeting the speed/time requirements. 

The technology solution investigated by Foyle et al. (2011, Expt. 4) was a speed 
indicator on the primary flight display (PFD) driven by an “error-nulling” 
algorithm. The speed algorithm dynamically compensated for speed-maintenance 
deviations by adjusting the current advised speed according to the remaining time 
and current distance to the RTA location. In addition to improved RTA error, pilots 
reported that the use of the algorithm/display did not compromise their out-the- 
window attention. 

1.2 Present Study 

The goals of the present study were three-fold: 

1) Test an improved version of the error-nulling algorithm/display that more 
precisely calculated and presented the speed required to reach the departure runway 
at an RTA. Specifically, advised speed was computed based on remaining time, 
distance, number of turns, turn speed, and specific rate of acceleration/deceleration. 

2) Evaluate that algorithm/display for robustness under multiple realistic 
conditions. The impact of the improved error-nulling algorithm on pilots’ ability to 
meet an RTA to the departing runway was tested under robust traffic and surface 
operation conditions, including taxi route changes, departure clearance changes, 
RTA changes, and a 2-min hold scenario. 

3) Assess the use and integration of flight deck DataComm in STBO. The 
present study also explored DataComm integration with flight deck displays. This 
integration allowed DataComm infonnation to be displayed graphically, which may 
improve situation awareness and extend the use of DataComm communication in 
time-critical situations. 

2 METHOD 

Twenty commercial pilots, with a mean age of 52 years (range of 36 - 63 years), 
participated in the study. Nine of the pilots were currently Captains and 11 were 
First Officers. The mean flight hours logged was 9,885 hours (range of 600 - 
17,000 hours). Pilots were paired by company affiliation to form 10 two-person 


crews. 



2.1 Flight Simulation 


The study was conducted in the Airport and Terminal Area Simulator (ATAS), 
in the Human-Centered Systems Laboratory at the NASA Ames Research Center. 
The airport environment was the Dallas-Fort Worth International Airport (DFW) 
with high visibility and distant fog/haze conditions. The forward, out-the-window 
scene was depicted on four LCD displays, with a total viewing angle of 140 deg. 
The modified-B737NG cockpit included a Primary Flight Display (PFD), 
Navigation Display (ND), and Flight Management System (FMS) Control Display 
Unit (CDU) on both crew members’ sides, and a shared Taxi Navigation Display 
(TND) and DataComm display with a touchscreen interface. Aircraft controls 
included a tiller on the Captain’s side, toe brakes, throttles, and emergency brake. 
The physical and handling characteristics of the aircraft were modeled after a B757. 

2.2 RTA Speed Algorithm 

Each departure taxi clearance included a required time of arrival (RTA) at the 
queue area of the departure runway. To aid the pilots in arriving on time, the flight 
deck was equipped with an algorithm that computed the straightaway speed 
required to precisely meet the RTA. The RTA algorithm dynamically computed the 
advised speed by accounting for remaining distance, remaining time to RTA, 
number of turns, an assumed acceleration/deceleration rate of 1 kt/sec, and a turn 
speed of 10 kts (per standard operating procedures, SOPs). Taxi clearance RTAs 
were calculated such that the initial advised straightaway speed was 15 kts. The 
algorithm was dynamic and compensated for the pilot slowing down or speeding up 
by appropriately increasing or decreasing the advised straightaway speed. 

2.3 STBO Experiment Displays 

The PFD was modified for taxi operations by expanding (doubling) the speed 
scale from 0-60 kts. Advised straightaway speed, as calculated by the RTA 
algorithm, was displayed as a magenta analog pointer (“speed bug”) on the speed 
tape and digitally in magenta directly above the speed tape (see Figure 1, panel 1). 
As shown in Figure 1 (panel 2), upon entering a turn, the magenta advised speed 
bug dropped to 10 kts (per taxi SOPs), while the white inner speed bug continued to 
dynamically indicate the straightaway speed required to meet the RTA. The PFD 
also included the current speed, shown as a sliding indicator with digital value 
inside (18 kts in Figure 1, panel 1), RTA time (Zulu) in magenta, and time 
remaining to the RTA (min:sec) in the white box. 

A Taxi Navigation Display (TND) depicted the airport layout to aid the pilots in 
airport navigation. The ownship aircraft’s position, shown as a white chevron, and 
other aircraft traffic within the ownship’s 1,250 ft declutter circle, shown as yellow 
aircraft icons, were updated in real time (see Figure 1, panel 3). When the initial taxi 
clearance, sent via the DataComm, was accompanied by preview information, the 
TND populated with details of route: a graphical route on an overview map, 



clearance text, RTA, time remaining to RTA (T Rem), route distance, and advised 
straightaway speed in cyan (see Figure 1, panel 3). Once accepted by the flight 
deck, clearance information was loaded into the PFD and the TND updated with the 
taxi clearance displayed as a magenta route, in perspective, track-up, and with text 
of the accepted clearance. When a mid-route taxi route change or RTA change was 
accompanied by preview information, the RTA, time remaining, distance 
remaining, and advised speed of the pending route were displayed in cyan. Turn 
graphics and route text were also displayed for taxi route changes. RTA location in 
the departure runway queue area was displayed as a white, dashed line across the 
ownship route on the TND, visible on the TND as the pilot neared it. 
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Figure 1 PFD: on straightaway (panel 1), and in turn (panel 2). TND: pending taxi route change 
with preview information in cyan (panel 3). DataComm: pending taxi route change (panel 4). 

The DataComm touchscreen interface was located aft of the throttles between 
the two pilots. At the start of the trial, the flight deck received a DataComm with an 
expected taxi and departure clearance, followed by an initial taxi clearance. Taxi 
route changes (Figure 1, panel 4), RTA changes, and departure clearance changes 
were delivered via the DataComm during taxi. The DataComm followed a format 
similar to the European Airport Movement Management by Advanced Surface 
Movement Guidance and Control System, Part 2 project (EMMA2; Airbus, Thales, 
DSNA, 2009). When a clearance was delivered via DataComm, three touchscreen 
response buttons were available to the pilot to respond to ATC: Unable, Standby, 
and Wilco. The DataComm display included the message sent time in the upper left 
corner, an indicator of message status in the upper right hand comer (i.e., “OPEN” 
while ATC was awaiting a response from the flight deck, or “WILCO”, “STBY”, or 
“UNABLE” after a response was selected and sent to ATC), and status of the 
connection (i.e., “COMM OK” or “RECEIVED BY ATC” when ATC received the 
crew’s response). After the crew responded “WILCO” to a clearance, the 
DataComm text turned magenta, as an indication of acceptance. 











2.4 Experimental Design 


Each crew experienced nine experimental trials (see Table 1 in Results, Section 
3). Taxi routes were constructed with 11,883 ft average distance and 8 min 2 sec 
average duration. The presentation of trials was randomly ordered and 
counterbalanced for each of the 10 crews. Each trial started at a ‘ramp spot’, had a 
unique route, and ended at the departure queue area. 

Four taxi route change trials were included with pilots receiving notification 
either 500 ft or 2,000 ft before the required turn, and with either Preview or No 
Preview information on the TND. Route distance was held approximately constant 
(within 950 ft), and the RTA and runway remained the same in these four trials. 

Two RTA change trials consisted of a revised RTA that was changed to 
approximately one minute earlier. These were given with either No Preview (57 sec 
earlier) or with Preview information (50 sec earlier) shown on the TND. In order to 
meet the amended RTA, an 18-kt straightaway speed was required in both trials. 

Two departure clearance change trials required the First Officer to reprogram 
the FMS by selecting a different departure and transition. The change occurred 
either early (at 25% into the route), or late (at 75% into the route). These clearance 
changes were sent and responded to via the DataComm. 

In the crossing traffic hold scenario, ATC gave instructions via voice to stop for 
two 777 aircraft — the RTA and route remained in effect. The crew was delayed for 
127 sec before being cleared by voice to continue taxi. Required straightaway speed 
increased to 21 kts during the 127 sec that passed while being held. 

2.5 Procedure 

Pilots were told that their primary goal in each trial was to minimize RTA error 
to the greatest extent possible so as to arrive at the departing queue area at the 
designated time. They were explicitly instructed to taxi as they would in a B757 
aircraft, and never to taxi faster than would be safe in the real world. Pilots were 
informed that the advised straightaway speed was provided as an aid to help them 
reach the RTA point on time, but that it was not a requirement to constantly follow 
it. They were also told that the algorithm was dynamic, and that it assumed a 10-kt 
turn speed and 1 kt/sec acceleration/deceleration rate. Pilots were instructed to not 
“track” the advised speed indicator, but rather to use it as a strategic indicator. 

Four initial taxi trials were presented to allow each crew to become familiar with 
the simulator, FMS, and experimental procedures. These trials also provided an 
opportunity for the pilots to experience the types of scenarios to be tested: a taxi 
route change, an RTA change, and a departure clearance change. Pilots were not 
provided with information about the crossing traffic hold scenario prior to its 
occurrence (or during familiarization trials). 

Each trial began with an expected taxi clearance sent to the flight deck via 
DataComm. The clearance included the expected taxi route, departure runway, 
RTA, and departure clearance. Conceptually, pilots were told that an expected taxi 
clearance would be received at the gate, 30 min prior to pushback. In addition to 



paper airport charts, the TND showed an overview map of DFW airport with the 
current ownship location. The expect-clearance DataComm allowed pilots to orient 
themselves to their initial location, taxi route, and departure runway. Crews were 
instructed to use this time to thoroughly review and discuss the taxi clearance and 
carefully plan their taxi route. The First Officer was responsible for managing the 
DataComm and programming the Flight Management System (FMS) for the initial 
departure clearance and departure clearance change while taxiing. 

After completing taxi route planning and FMS entry at the gate, the simulation 
advanced to a ramp departure spot. Upon receiving the crew’s ‘ready to taxi’ call, 
the experimenter initiated an ATC-sent DataComm with the initial taxi clearance to 
the flight deck. In three No-Preview trials (see Table 1), the initial taxi clearance 
was not accompanied by preview information on the TND. The six remaining trials 
included preview information on the TND. In particular, the preview of advised 
speed allowed pilots to quickly understand whether, given the route distance and 
number of turns, meeting the RTA would be reasonable. The graphical depiction of 
the taxi route on the overview map facilitated understanding of the clearance. In all 
trials, pilots were to review and accept or reject the initial taxi clearance with RTA 
as soon as possible after receiving it, because the time to the RTA was counting 
down. Time remaining (“T Rem” in cyan on the TND in Figure 1, panel 3), prior to 
acceptance of the clearance, was only visible to the crew in trials with Preview. 

If the crew accepted the clearance, the First Officer responded by selecting 
“WILCO” on the DataComm, and the Captain released the emergency brake and 
began taxi. When the clearance was accepted, the RTA, time remaining, and 
advised speed were loaded into the aircraft avionics and displayed on the PFD (see 
Figure 1, panel 1), while the magenta route was displayed on the TND (panel 3). 

During each of the nine experimental trials, the crew received a taxi route 
change, an RTA change, a departure clearance change, or a verbal instruction from 
ATC to stop for crossing traffic. When a taxi route change was accompanied by 
preview information (see Figure 1, panel 3), pilots were able to use the cyan 
graphical route depicted on the TND to note their position and locate the required 
turn. When an RTA change was accompanied by Preview, pilots were able to use 
the advised speed to determine whether it was reasonable/acceptable to meet the 
revised RTA. 

In the event that the crew decided they could not comply with the initial taxi 
clearance or any of the three change clearances, pilots were to notify ATC by 
responding “UNABLE” via DataComm. If pilots decided they were unable to meet 
the RTA at any time during taxi, they were instructed to contact ATC via voice. 
When pilots reported they were unable to meet the RTA, by either DataComm or 
voice, ATC instructed them to “continue taxiing and minimize RTA delay.” 

Conceptually, pilots were told that they would receive their takeoff clearance 
after crossing the RTA location in the queue area. For this reason, they were 
responsible for completing any FMS programming changes prior to reaching the 
RTA location. Pilots were instructed to continue taxiing after crossing the RTA 
location; with the trial ending shortly after that point. 

Following completion of the trials, pilots estimated the minimum required 



notification distance using voice, DataComm text only, and DataConnn with 
Preview for: a taxi route change, an RTA change, a runway change, and a departure 
clearance change. Pilots estimated these minimum notification distances on a post- 
study airport chart showing a taxi route with a distance scale. 

3 RESULTS 

The primary measure of pilot performance on the taxi task was RTA error, 
calculated by subtracting the RTA from the observed arrival time. (Negative RTA 
errors indicate early arrival; positive RTA errors indicate late arrival.) As shown in 
Table 1, RTA error is very good (near zero) across all conditions. 


Table 1 Mean RTA Error in Seconds (S.E.) 


Taxi Route Change (Same RTA) 

Speed and Turn 
Graphics Preview 

No Preview 

500 ft turn notification 

-0.43 (1.11) 1 

4.14 (1 .81) 5 

2,000 ft turn notification 

-0.99 (1.19) 

1.39 (1.02)* 

RTA Change (15 kts to 18 kts) 

Speed Preview 

No Preview 

57 sec earlier 

— 

3.71 (1 .01 ) 1 

50 sec earlier 

0.08 (0.29) 

- 

Departure Clearance Change (Early) 

-2.30 (1.09) 

Departure Clearance Change (Late) 

-1.57 (1.21) 

127-sec Crossing Traffic Hold (via voice) 

4.96 (3.76) 2 


Notes: Superscript indicates number of crews (of 10) that responded “UNABLE” 
* One crew stopped because they misunderstood the clearance, arriving 1 61 .34 
sec late. Only this one outlier was removed from the RTA error analysis. 


DataComm responses other than “WILCO” are noted as superscripts in Table 1. 
Note that even though pilots responded “UNABLE” in some cases, they were still 
able to meet the RTAs with relatively small RTA error (with one exception noted). 

Statistical tests did show some differences among means: With a Taxi Route 
Change (Table 1 top two rows), RTA error was greater with No Preview than with 
Preview, F’(l,9)=4.89, p=. 05; and, for RTA Change, RTA error was greater with No 
Preview than with Preview, f(9)=3.44, p<.01. There was no significant effect of 
location of departure clearance change (early or late in route) on RTA error. 

It should be noted, however, that despite these significant findings, the important 
point is that these are all very small RTA errors, especially when put in the context 
that the taxi routes were, on average, more than 8 minutes in duration. (All RTA 
errors were also equivalent to zero, except for the No Preview 500-ft taxi route 
change, t(9)=2.29, p<.05, and the No Preview RTA Change, r(9)=3.67, p<.0l.) The 
most notable “robustness finding” is that despite being held for crossing traffic for 
more than 2 minutes (specifically, 127-sec), RTA error was under 5 seconds, and 
was statistically equal to (i.e., not different from) zero, t(9)=1.32,£>>.05. 

As in Foyle et al. (2011), to assess visual attention to the error-nulling speed 




display, pilots (only the last n=12 pilots tested) were asked, using a 5-point scale, 
where l=Rarely, 2=Seldom, 3=Sometimes, 4=Frequently, and 5=Most of the Time, 
“During this trial, how often did you find yourself focusing on the speed and/or time 
displays when you should have been paying attention to the external taxiway 
environment?” Results (M=2.13, SD= 0.62) indicated that pilots responded that the 
error-nulling algorithm/display did not negatively impact their visual attention to the 
out-the-window airport view, as was found in Foyle et al. (2011, Expt. 3). 

3.1 DataComm Notification Distance 

On a post-study questionnaire, pilots estimated the minimum distance that they 
were willing to accept a taxi route change, an RTA that was 1 min earlier, a change 
to a parallel runway, and a departure clearance change. Pilots provided distances for 
three communication types: DataComm with Preview information, DataComm text 
only (No Preview), and voice only. Participants indicated their responses on a 
taxiway map overlaid with a distance scale. Mean (and S.E.) minimum notification 
distances (ft) are shown in Table 2. 


Table 2 Mean Minimum Notification Distance in Feet (S.E.) 


Minimum Notification Distance (ft) Required before Taxi Route Change 

Type of Change 

DataComm 
with Preview 

DataComm 
No Preview 

Voice Only 

Taxi Route Change 

895 (178) 

1,378 (119) 

928 (149) 


Minimum Notification Distance (ft) Required before Runway Takeoff Clearance 

Type of Change 

DataComm 
with Preview 

DataComm 
No Preview 

Voice Only 

RTA Change (1 min earlier) 

4,856 (489) 

5,825 (488) 

5,675 (536) 

Change to Parallel Runway 

2,763 (395) 

3,025 (386) 

2,785 (417) 


Type of Change 

DataComm 
(No Preview) 

Current Day Voice 
Environment 

Departure Clearance Change 

2,600 (307) 

2,986 (387) 


For a 1-min RTA change, pilots required a shorter notification distance for 
DataComm with Preview, F’(2,38)=8.14, p< 01. For a taxi route change, pilots 
required a longer notification distance for DataComm No Preview, F(2,38)=l 1.22, 
p<. 01. That is, pilots indicated that DataComm with Preview (i.e., preview of 
advised speed or route change graphic) could be used in place of voice in these 
scenarios. There was no significant effect of communication type on minimum 
distance notification to a parallel runway change or a departure clearance change. 


4 DISCUSSION 

The present study tested a version of an error-nulling algorithm that more 
precisely calculated advised speed by accounting for remaining time, distance, 




number of turns, turn speed, and acceleration/deceleration rate. The improved RTA 
algorithm was tested under robust traffic and surface operation conditions, including 
taxi route changes, departure clearance changes, RTA changes, and a 2-min traffic 
hold scenario. RTA error in the present study was near zero across all trials, 
indicating that pilots were able to meet the RTA with very little time error, and that 
meeting this RTA did not interfere with visual attention out-the-window. 

Typically, it has been noted (e.g., Jakobi, 2007; Wargo and D’Arcy, 2011) that 
DataComm may not be appropriate for time-critical situations. In this study, pilots 
reported that for taxi route modifications with a graphical preview of the required 
turn and for RTA changes with a preview of the advised speed, DataComm requires 
the same, or less, notification distance as voice communication. This potentially 
important finding suggested by these results is that DataComm with graphical 
preview information may be usable in more situations than previously considered 
(presumably, of course, when non-compliance would not result in an unsafe 
condition). Clearly, more research is needed, but these results suggest that with 
DataComm information integrated and displayed on a flight deck display, reverting 
to voice communication may not be required for some time-critical communications 
as was previously considered. 
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